The rapid advancement of digital media in the areas such as music and movies has given rise to content protection issues. Unlike content stored in analog form, content stored in a digital form can, in the absence of some protection mechanism, be easily and accurately copied and distributed almost without limits. Of course, this issue is very significant to owners and producers of such digital content. While there are legal remedies to protect content owners and producers, these parties have increasingly turned to techniques that provide the parties themselves control over the reproduction and use of content. Typically, these techniques employ some form of data encryption.
Encryption of messages, information and data has been around almost as long as writing. Julius Caesar employed a system that substituted one letter for another; Leonardo Da Vinci wrote manuscripts in a reverse image so that they could only be read in a mirror. One current method of protecting data is a private key encryption, or “shared key,” system in which a key, known only to a sender and a recipient, is used to encrypt and decrypt a message.
In the early 1970's, a private key encryption system called Data Encryption Standard algorithm (DES) was introduced, which uses a fifty-six (56) bit key to encrypt and decrypt information. DES splits a message into blocks and then encodes each block. DES is no longer considered adequately secure because a 56 bit key can be broken in a relative short time by trying every possible key. DES has since been superseded by the Advanced Encryption Standard (AES), using what is known as the Rijndael algorithm. AES operates with 128, 192 or 256 bit keys. These keys are considered long enough to be safe for the foreseeable future as they would take millions of millions of years for the fastest currently available computers to break.
A second current method for protecting data is public key encryption, which has been around for approximately twenty-five (25) years. Public key encryption involves the use of two keys: a public key, know to everyone, and a private key, known only to the recipient of a message. Although public key encryption is very effective, there are several drawbacks when it is applied in the realm of digital content protection. First, public key encryption is computationally expensive, i.e. public key systems require such significant computational capacity they are normally only used to implement a key exchange process within a private key encryption system, not to encrypt the body of a message. This process requires a two-way communication, which is not necessarily available in the distribution of protected media. Secondly, once the private key of a public key system has been compromised, the system becomes a shared key system. Thirdly, once a public key system has been compromised, there is no practical method for “revoking” the compromised private key.
Another example of a protection scheme for digital media is digital video disk (DVD) media, which was first sold in Tokyo, Japan in 1996, relies upon a Content Scrambling System (CSS). CSS relies upon a shared secret code. The CSS code was broken by a hacker in 1999 and it is now easy to find programs on the Internet that will decrypt a DVD protected by CSS. Now that the system has been cracked, there is no way to fix it without redesigning the entire system. In other words, the shared code that forms the basis of CSS can not be revoked and a new code issued as a replacement.
A recent development in the field of encryption of digital media is broadcast encryption. Broadcast encryption are based upon a key management block (KMB), which is a block of data sent at the beginning of a broadcast or is prerecorded on blank media during the manufacturing process. One of the largest advantages to broadcast encryption is that two devices, which might be previously unknown to each other, can agree upon a key over a one-way communication path. This advantage makes broadcast encryption ideal for the downloading of digital content from a server to a user.
The International Business Machines Corporation (IBM) of Armonk, N.Y., a leader in broadcast encryption, has developed a content protection system referred to as eXtensible Content Protection (xCP) designed for networks and media distribution. This technology is based on broadcast encryption and supports the notion of a trusted domain that groups together compliant devices. Content can freely move among devices within the trusted domain but is useless to devices that are outside of the domain. XCP provides a cryptographically strong yet extremely flexible model for access to copy-protected content within a network of devices.
Based on IBM's experience with broadcast encryption, xCP was designed to meet the following requirements:                1. Cryptographically strong;        2. Easy to use, if not transparent, to consumers;        3. Low compute requirements;        4. Exclusion/renewal in the case of a breach;        5. Compatible with rights management and other copy protection systems; and        6. Encourages the implementation of new content owner business models.Extensible content protection (xCP) makes use of the key management scheme described by broadcast encryption and can be thought of as a superset of the successful content protection technology used and licensed today by IBM on DVDs, High Definition DVDs (HDVDs) and Compact Disks (CDs) called Content Protection for Recordable Media (CPRM).        
Public-key based systems, which require devices to have a two-way conversation to establish a key, are almost impossible to completely divorce from an underlying transmission protocol. The IBM xCP Cluster Protocol may be the first system directed to peer devices based upon broadcast encryption as the underlying cryptographic technology. Devices that implement the xCP Cluster Protocol and its broadcast encryption mechanisms are said to “bind” the content they protect to a particular entity (e.g. a home network or cluster) by encrypting the content with a different key, called the binding key (Kb), than the one produced by processing a KMB, as explained below. All current approaches to binding a piece of content to a particular entity, regardless of whether it is a piece of media, a device, or a user, is through one level of indirection in the calculation of the encryption keys. In these cases, the procedure to encrypt a piece of content is roughly the following:                1. Extract a Management Key (Km) by processing the KMB.        2. Perform a one-way function to a piece of data that uniquely identifies the entity this content is being bound to (or the “IDb”), using Km and resulting in a binding key (i.e. Kb=G(Km, IDb)).        3. Choose a random title key (Kt) for this piece of content and encrypt it using Kb, resulting in an encrypted title key (EKt) (i.e. EKt=E(Kb, Kt)).        4. The content is encrypted with the Kt and then the encrypted content is stored in conjunction with the EKt.Once the procedure has been implemented, any compliant device that has access to the same KMB, IDb and EKt can decrypt the content by reproducing the same Kb and decrypting Kt.        
In various binding scenarios there is more than one piece of content that is bound to the same entity and, at the same time, either the KMB or IDb can change. The result of this is that the value of Kb changes and thus all the existing title keys need to be re-encrypted with the new value of Kb—otherwise, no device would be able to open the content again. It should be noted that encrypted content of this nature is routinely exchanged and/or copied between entities which participate in the described binding scheme.
One issue that arises in the context of content protection is providing for the expiration of the right to access material. For example, a user who downloads a movie may pay for the right to display that movie for forty-eight (48) hours. The current art for managing encrypted content that is subject to expiration relies upon comparing a standard timestamp against a secured clock. This method requires that both a secure clock and a communication link to the secure clock are always available. What is needed is a method that allows a device to make a determination on the expiration of encrypted content without requiring either access to a secure clock, whether the clock is local or remote, or a functional communication link.